Azure DevOps 的敏捷式流程圖

敏捷式專案管理的最佳做法

之前有說到，使用者開始保留大量Issue，那有一些Issue值得被設計進功能藍圖中。
因此，這一天要來講述SDLC的第二步，我們要來開始實現使用者的願望了。

Azure 的Agile Project 及Scrum Project，基本上是完全可以支援敏捷式開發方式，所以我們要先讀懂他的專案所定義出來的各個組成。由於筆者其實並不是個敏捷式專家，公司也沒有這種團隊，只有上過一些課，並大量參考微軟的文件或是網路上的知識，最終把Azure DevOps的各個功能與使用方式，想辦法轉化為可以被內部接受的軟體開發交付方式。因此，對於敏捷式開發的部分並不會做太多著墨，還是以完成任務為主。

先來簡述每個組成的關係：

1. Epic
   1. 最上層。
   2. 翻譯過來是史詩？遠大的目標？
   3. 可以思考成例如年度計畫、第一期交付項目。
   4. 目前這個work item對我們而言很模糊，特別是如果維護型的系統可能沒這麼遠大。
2. Feature
   1. Epic 下層，代表在這個目標下，這次要被完成的功能集。
   2. 一個軟體系統必然會有許多的功能會被完成，所以Feature代表的是各項軟體系統中的功能。
3. User Story
   1. Feature 的下層，代表在某個功能下，使用者對他的期待。
   2. 這裡我認為是最貼近需求的地方，user以一個故事的形式來敘述他遇到的問題，或是希望被滿足的事項。
   3. User Story 不需要提供技術實作方式，但一定要提供驗收的標準。
4. Task
   1. User Story 或Bug的下層，代表在要滿足使用者的願望之下，或是要修正一個Bug，需要被安排出去的工作。
   2. 工作可以包含軟體開發項目，或是非開發項目的工作。

Feature & User Story

其實在以前並沒有把功能、使用者的願望把他分開思考的。以往通常都是使用者提出了一大堆的想法與痛點後，根據開發人員(我們通常分析兼開發）喜好，自己就開始規劃系統該如何設計了。這種系統設計形式，那就可能會出現為了滿足一個故事就寫出一個功能的狀況，那多年後就會發現一個小小的系統，功能居然多達50個，因此就可能會造成使用者很難根據自己的目的，容易的找到自己要用的功能。

但如何切功能，其實是屬於軟體設計的範疇，例如可以使用Event Storming或是進階的DDD，這一段就不在這裡贅述，先討論工具本身該如何被使用為主。

Feature
其實組成的欄位非常的簡單，主要最大的欄位就叫做Description。以我們的看法就是，其實就是在經過討論後，決定做出這個功能，對於這個功能的敘述。但是這個敘述並不會代表要把整個功能的邏輯都要塞在這個欄位中，因為一個功能的完成，是可以乘載多個使用者的願望的，因此大多數的邏輯會被放在下層User Story中。

User Story
使用者劇本這裡要表達的是，使用者對於他需要被解決的問題、想要做的流程或是希望被滿足的願望。這裡與Feature 最大的不同，就是要有Acceptance Criteria（驗收標準）。在我們的想像中，這就是一個使用者開需求的地方，只要工作項目有滿足了使用者驗收的標準，就應該要被交付準備測試與驗收。

這時候，還沒有要開工（寫程式），這邊都還在專案管理以及系統分析的階段。如同我前面說的，我們都是碼農兼系統分析，另外還兼維運、客戶服務以及其他庶務。所以要能夠多正統的使用這個工具，目前我們也都還沒有個底，就邊走邊看了。

我只是想寫快樂的程式，怎麼永遠都離快樂都還有最後一哩路